Hier geht´s zum aktuellen .NET Core 2.0 Beitrag

Herr Nagel, welches neue Konzept verbirgt sich hinter .NET Core 1.0?

Es ist eine Version 1, auch wenn es bei RC1 noch .NET Core 5.0 war. Version 1 ist aber viel zutreffender. Version 1 heißt aber nicht, dass noch nicht viel dabei ist – im Gegenteil, .NET Core ist jetzt schon riesig. Version 1 soll mehr darauf hinweisen, dass es sich um einen Neustart handelt, es ist ein neues .NET.

Um die Konzepte auf die .NET Core aufbaut zu beleuchten, macht es zuerst Sinn, die Gründe die zu .NET Core führten zu beleuchten:

• Schnellere Innovationen

NuGet Packages, die schon mit dem .NET Framework eingeführt wurden, ermöglichen schnellere Updates als wir es mit dem .NET Framework gewohnt waren. Als .NET 1.0 im Jahr 2000 vorgestellt wurde, war es noch möglich auf Update-Zyklen von ca. zwei Jahren aufzubauen. Heute ist das nicht mehr möglich, wir wollen schneller auf neue Features zugreifen. Mit einigen Bereichen vom .NET Framework ist das auch schon geschehen. Entity Framework 6 wird komplett aus NuGet Packages geliefert, zudem auch z.B. System.Collections.Immutable und System.Collections.Concurrent. Allerdings: Funktionalität, die bereits mit dem .NET Framework am System installiert ist, und auch die Common Language Runtime kann nicht so einfach ausgetauscht werden, um neue Features anzubieten. Dazu sind Administratorrechte notwendig. Entity Framework selbst hatte viele Jahre darunter gelitten, dass dieses Framework teilweise mit dem .NET Framework am System installiert wurde und zusätzliche Klassen über NuGet Packages gekommen sind. Damit gab es einige Einschränkungen.

Bei .NET Core 1.0 kommt jetzt alles über NuGet Packages – auch die Runtime. Das ermöglicht schnelle Innovationen in allen Bereichen.

Nachdem mit Applikationen jetzt auch die Runtime ausgeliefert wird, muss ich mit Webanwendungen nicht mehr darauf warten, bis mein Provider die neueste .NET Version am Server installiert hat. Welche Version ich verwende, entscheide ich jetzt mit der Applikation.

• Komplexität des .NET Frameworks

Das .NET Framework ist im Lauf der Jahre sehr komplex geworden. Viele Teile im .NET Framework bestehen auch aus Libraries, die in neuen Applikationen heute nicht mehr benötigt werden, z.B. .NET Remoting, LINQ to SQL, die alten Non-Generic Collection Klassen und viele mehr. Wenn man die letzten Jahre mit .NET mitgewachsen ist, ist das weniger ein Problem. Sehr wohl ist es aber ein Problem für Neueinsteiger in .NET. Wie soll hier entschieden werden können, welche Klassen verwendet werden sollen und welche Teile nicht mehr „State of the Art“ entsprechen?

Nachdem alle Teile von .NET Core jetzt in kleineren NuGet Packages geliefert werden, ist es möglich Referenz-Packages zu definieren. Entwickler können diese Referenz-Packages nutzen. Damit ist dann auch gleich definiert, welche Packages mit welchen Versionen in der Firma genutzt werden sollen/dürfen. Das hilft Neueinsteigern Entscheidungen zu treffen und nicht gleich das riesige .NET Framework vor sich zu sehen.

• Cross-Platform

Windows auf allen verschiedenen Devices unterschiedlichster Art und Größen zu haben – vom Desktop und Smartphone über die HoloLens und IoT Devices ist schön. Die tatsächliche Verbreitung kann aber nicht außer Acht gelassen werden. Auf mobilen Devices haben Android und iOS weit größere Marktanteile, und am Server ist Linux weit verbreitet.

Ein großer Vorteil von .NET Core 1.0 ist etwas, das bisher nicht von .NET abgedeckt werden konnte: .NET auf Linux und OS-X – und zwar mit Support von Microsoft. Es war schon spannend zu sehen, wie rasch weitere Plattformen unter https://www.github.com/dotnet hinzugefügt wurden und praktisch alles gleich funktioniert. Ich habe inzwischen auch Vorträge auf Linux-Konferenzen gehalten. Vor wenigen Jahren war das noch nicht vorstellbar. .NET Core haben wir auf unterschiedlichen Plattformen – und auch die Tools!

• Open Source

Dass .NET Core – inklusive der Runtime, dem C#-Compiler und ASP.NET MVC 6 – jetzt Open Source ist, hat große Vorteile. Man muss ja jetzt nicht gleich selbst Erweiterungen schreiben oder Bugs korrigieren. Ich bin seit frühen Betas dabei – so kann man auch Design-Entscheidungen mitverfolgen. Warum manches so oder so gelöst wurde, ist so leichter zu verstehen.

Zu Erweiterungen von C# 7 und auch schon C# 8 ist es z.B. jetzt möglich, Feedback zu geben und selbst die nächsten Versionen von C# zu beeinflussen. Wie erwähnt: Bug-Fixes müssen nicht selbst gemacht werden. Ich hatte mehrere Bugs auf GitHub reported. Bei einem meiner Reports habe ich ursprünglich nicht damit gerechnet, welchen Impact der Bug dann letztendlich wirklich haben würde. Aber nach nur sechs Tagen gab es einen Fix in den Daily Builds. Über GitHub lässt sich so direkt mit den .NET-Entwicklerteams kommunizieren. Erweiterungen zu schreiben, die dann auch verwendet werden können, ist natürlich auch möglich.

.NET Core 1.0 ist wirklich eine neue Welt: .NET-Code auf unterschiedlichen Plattformen, Open Source und in vielen kleinen NuGet Packages. .NET Core ist bereits in der ersten Version riesig.

Der .NET Framework & C# Track auf der BASTA! Konferenz

Wie schätzen Sie den aktuellen Stand von .NET Core 1.0 ein?

Aktuell haben wir RC2, RTM soll am 27. Juni 2016 verfügbar sein. Go live ist jetzt schon mit RC2 möglich (und der 27. Juni ist ja bald). RC1 als „Release Candidate“ zu verkaufen war ein Fehler, der Name hat sich geändert, damit auch Namespaces und Package Namen sowie auch noch das API selbst. Ich sehe RC1 nicht als „Release Candidate“ – und Microsoft mittlerweile auch nicht mehr. Mit RC2 ist das aber anders. Während es von RC1 zu RC2 noch große Änderungen gegeben hat, ist RC2 ein wirklicher „Release Candidate“. API-Schnittstellen werden nur noch geändert, wenn kritische Probleme auffallen. Die Tools werden sich noch ändern, die sind beim Release von .NET Core auch erst Preview 2. Ein Release der Tools einige Monate später ändert aber nichts an der fertigen Applikation.

.NET Core 1.0 ist jetzt einsetzbar, die meisten neuen Applikationen würde ich auch jetzt damit implementieren.

Welche Vorteile bringt .NET Core 1.0 für Entwickler?

Ein großer Vorteil von .NET Core 1.0 liegt darin, dass .NET jetzt auf anderen Plattformen verfügbar ist – nicht mehr nur Windows, sondern auch Linux und OS-X. Das ermöglicht den Einsatz von .NET in Szenarien, die früher einfach nicht möglich waren.

Darüber hinaus ist .NET Core 1.0 einfach moderner. Das .NET-Framework hat doch einige Jahre auf dem Buckel, inklusive unterschiedlichster Patterns, die implementiert wurden. Ich denke da z.B. an die unterschiedlichsten asynchronen Patterns, die seit .NET 1.0 entstanden sind, und auch im .NET-Framework durchgehend implementiert wurden. Alte Zöpfe konnten mit .NET Core abgeschnitten werden. .NET Core hat moderne Patterns im Einsatz. Dass Dependency Injection tief im Framework integriert ist, wird rasch erkannt, sobald man sich mit ASP.NET Core beschäftigt. Ich verwende Microsoft.Extensions.DependencyInjection aber nicht nur mit ASP.NET Core, sondern auch mit WPF- und UWP-Applikationen. Außerdem gibt es eine neue, flexible Konfiguration und neue Logging Interfaces mit denen bestehende Logging Frameworks verwendet werden können.

Neue Tools für die Command Line sind auch da. So ist es mit dem dotnet Command möglich, den initialen Source Code zu erzeugen, NuGet Packages zu laden und zu erstellen, das Programm zu kompilieren, zu testen, User Secrets zu managen, Entity Framework Migrations durchzuführen und vieles mehr. Dabei enthält das Tool nicht gleich alle Features, sondern es ist erweiterbar.

.NET Core 1.0 ist einfach ein modernes Framework, das die Bedürfnisse von heute erfüllt.

Wo sehen Sie aktuell Schwächen der neuen Version?

Mit dem Release von .NET Core 1.0 stehen die Tools nur als Preview zur Verfügung. Der eigentliche Release der Tools steht erst mit der nächsten Version von Visual Studio, Visual Studio „15“, auf dem Programm. Mit den Tools wird sich dabei aber auch noch viel ändern. Was mich schon immer bei .NET Core gestört hatte, ist, dass einige Tools in Visual Studio einfach nicht für diese neue Technologie zur Verfügung stehen. Der Grund: Die Tools müssten erst für das neue Projektformat von .NET Core angepasst werden. Microsoft hat aber einen Weg gefunden, doppelte Arbeit zu vermeiden. Statt diese Tools für .NET Core 1.0 anzupassen, werden in MSBUILD jetzt Features integriert, die die Vorteile von project.json ausmachen. Als Ergebnis davon werden wir ein neues Projektformat haben, das sowohl von .NET Core als auch .NET-Framework-Applikationen genutzt wird – und zwar auch auf anderen Plattformen, unabhängig von Visual Studio. Das einzige Problem dabei ist, dass es noch etwas dauert, bis das neue Projekt-File da ist.

Für den aktuellen Einsatz von .NET Core 1.0 soll das aber kein Hindernis sein. Sobald das neue Projekt-File verfügbar ist, werden bestehende Projekt-Files automatisch konvertiert – zumindest ist das der Plan. Diese Änderungen beeinflussen den C# Source Code aber keineswegs, und damit sehe ich das gar nicht so problematisch.

Eine weitere Schwäche kann die Problematik beim Portieren älterer Applikationen auf .NET Core sein. Es ist zwar von Vorteil, dass alte Zöpfe abgeschnitten wurden. Allerdings bringt das aber auch gleich den Nachteil mit sich, dass es schwierig ist, bestimmte Applikationen nach .NET Core zu portieren. Einige APIs gibt es einfach nicht in der neuen Welt. Es fehlen z.B. Application Domains, der alte, mächtige Syntax für Reflection und einiges mehr. Ein Hilfsmittel, um herauszufinden, wie weit eigene Applikationen davon betroffen sind, ist die Visual Studio Extension „.NET Portability Analyzer“. Dieses Tool zeigt die betroffenen genutzten APIs und manchmal auch Alternativen dafür.

Zukünftige Versionen von .NET Core werden dann den Umstieg von Legacy Applikationen zu .NET Core erleichtern. Application Domains, Reflection und mehr werden in zukünftigen .NET Core Versionen auch zur Verfügung stehen.

Aus der eigenen Projekterfahrung gesprochen: Wer sollte jetzt schon umsteigen?

Es gibt jetzt einige Szenarien, die früher mit .NET einfach nicht möglich waren. Da ist es einfach, sich schon jetzt für .NET Core zu entscheiden, z.B. um .NET-Applikationen auf anderen Plattformen zu ermöglichen.

Entity Framework Core ist ebenfalls auf anderen Plattformen verfügbar, bietet aber außerdem noch die Möglichkeit, NoSQL Provider zu verwenden. NoSQL Provider sind aber momentan nur in Samples verfügbar – da sollte es nicht lange dauern, bis verschiedenste Provider zur Verfügung stehen. Mit der neuen Architektur von Entity Framework ist es auch leichter Provider zu schreiben.

Bei neuen Webapplikationen sehe ich auch kaum Gründe, ASP.NET MVC 6 nicht zu verwenden. Es gibt viele Ähnlichkeiten mit ASP.NET MVC 5. Und als ASP.NET MVC Entwickler findet man sich rasch zurecht. Im Hintergrund ist aber sehr viel anders.

Bei bestehenden Applikationen macht es meist noch keinen Sinn, diese gleich auf .NET Core umzustellen. Bestehende Applikationen können aber trotzdem schon Features von .NET Core nutzen, die einige Vorteile bieten, wie z.B. das neue Dependency Injection Framework, das neue Configuration API oder auch die Logging Facade. Diese NuGet Packages können auch mit „Legacy Applications“ genutzt werden.